home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 1220 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: news.rotterdam.luna.net!news
  2. From: poing@luna.nl (Paul van der Valk)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 12 Jan 1996 23:27:43 GMT
  6. Organization: Luna Internet Services
  7. Message-ID: <2022.6585T1348T2429@luna.nl>
  8. References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET>
  9.     <2152.6561T63T2136@cycor.ca> <4b7i18$si1@vixen.cso.uiuc.edu>
  10.     <oj6raxxrr0o.fsf@hpsrk.fc.hp.com> <13213431@sourcery.han.de>
  11.     <4cpmlv$obe@ousrvr3.oulu.fi> <4cqqfq$khf@serpens.rhein.de>
  12.     <4csgvl$dje@ousrvr3.oulu.fi> <4ctfr5$7v@serpens.rhein.de>
  13.     <4cvp0u$925@ousrvr3.oulu.fi> <4d069j$9ma@serpens.rhein.de>
  14. NNTP-Posting-Host: 08-static-a.rotterdam.luna.net
  15. X-Newsreader: THOR 2.1 (Amiga;TCP/IP beta 5)
  16.  
  17.  
  18. Michael van Elst writes:
  19.  
  20. >kinnunen@stekt.oulu.fi (Teijo Kinnunen) writes:
  21.  
  22. >>If memory protection were introduced, the only problematic area is
  23. >>interprocess messaging.
  24.  
  25. >No. It is shared access to data structures. If it only were the
  26. >messages we had no real problem.
  27.  
  28. I've been thinking about this for a while. There is plenty of read-access
  29. to shared datastructures in the amiga environment, but on how many occasions
  30. do you WRITE to shared memory? I can think of one example: the Disable()
  31. assembly macro. Any others? I think that 99% of (application level) shared 
  32. memory access is read-access. 
  33.  
  34. I'll settle for a MP scheme where every task has read access to the entire 
  35. address range, and read/write access to 'private memory'. This writable
  36. memory should be allocated using a new AllocWritableMem() (or something)
  37. call.
  38.  
  39. Let's get practical. Suppose that an upcoming OS supports the following:
  40.     (1) an AllocWritableMem() function.
  41.     (2) a NewDisable() function.
  42.     (3) some MMU magic for existing OS-code that modifies shared memory
  43.         (think about screen locking etc.)
  44.  
  45. New applications would call (1) and (2) instead of the existing AllocMem()
  46. and Disable(). Point (3) is completely transparant to the application.
  47.  
  48. It will be very easy to recompile existing code in this new style. 
  49. The current messaging system can be left unmodified, provided that the 
  50. receiving task doesn't modify the message data.
  51.  
  52. Cons:
  53.    - Old style apps can still corrupt foreign memory.
  54.    - New style apps can still read from illegal memory (no problem with me).
  55.  
  56. Pros:
  57.    - New style apps are safe to use. They can be corrupted themselves by
  58.    old style code, but they won't harm others.
  59.    - Old code can still be used (at the risk of trashing memory).
  60.    - Existing software can be easily recompiled for the new scheme.
  61.    - Relatively easy to implement at OS-level.
  62.  
  63. There are some details I haven't gone into but I don't see them as 
  64. problematic. What do you think of it? Am I overlooking something? :-)
  65.  
  66.  
  67. Paul
  68.  
  69.  
  70.